Floppyshop 2/Floppyshop - 2.zip/Floppyshop - 2.iso/diskmags/0022-3.564/dmg-0082/81.txt

Text File | 1997-04-16 | 15KB | 330 lines

=========================================================================

INFO-ATARI16 Digest         Mon, 22 Jan 90       Volume 90 : Issue   81

Today's Topics:
                      Facts, not only talking a
                            Overscan stuff
                              ST Format
                       ST S/ware Rental Places
                         TURBO C/MAS problem
----------------------------------------------------------------------

Date: 22 Jan 90 20:19:35 GMT
From:
 zaphod.mps.ohio-state.edu!samsung!cs.utexas.edu!jarvis.csri.toronto.edu!utgpu!w
 atserv1!watdragon!tiger![e-mail]  (Steven W. Klassen)
Subject: Facts, not only talking a
Message-ID: <[e-mail]>

In article <[e-mail]> [e-mail] (Steve
 Rehrauer) writes:

>But if you're going to do anything more than that on the ST, you have a
>choice of rolling your own graphical interface or using GEM.  You can
>carefully package the GEM stuff and hope that it'd be fairly painless
>to replace that portion with the appropriate MAC OS / MS-Windows / Amiga
>Intuition / Xlib / Display Postscript / whatever calls when you port.
>You still have to know GEM, though, and as matters & market-share stand
>today that's pretty machine-dependent anyway.

I have to agree...one can't be 100% portable, however, I believe with
some careful coding one can come pretty close.  (Graphics are something
of an exception though.)  I guess the point that I was trying to make
was to try to avoid the attitude of developing for a certain machine.  If
your general algorithm (ie. most of the program) is portable all the
little details (like graphics - ie. GEM) can be isolated.  That way
it's not too hard to move to another machine (you don't have to
rewrite the entire program, just certain parts).

In the Atari ST world I would say that almost no software developer
would need the details of Atari's package.  All you really need to
know are the system calls and their formats.  How they actually do what
they do should be left up to Atari (and subject to change).  This
information can be found in any number of manuals available at any
good (and even most not-so-good) Atari stores.  (I've got about all
the info I need from the MWC manual and another book that looks at
it from an assembly language point of view.  I don't recall the name
of that book off hand.)

The only advantage I can see from the official developer's package
would be if you get advance warning of changes in the programmer's
interface (ie. new or revised system calls) or special prices on
certain hardware/software.  I don't know if Atari's package includes
either of these since I have never bothered to look into it.

Steven W. Klassen                       +-----------------------------+
Computer Science Major                  | Support the poor...buy fur! |
University of Waterloo                  +-----------------------------+

------------------------------

Date: 22 Jan 90 21:01:29 GMT
From: zaphod.mps.ohio-state.edu!math.lsa.umich.edu![e-mail]
 (Howard Chu)
Subject: Overscan stuff
Message-ID: <[e-mail]>

(From a private message...)
%There seem to be a lot of details to consider:
%
%- what is the best hw mod?  A local guy has a version which flips
%  between overscan and normal under control of an unused pin in the
%  sound chip (it may be another chip, my memory is unreliable).
This sounds likely, but I'm not sure how useful it'd be. I think
having the definite control that a physical switch gives makes me
feel a bit more secure overall... But it also sounds convenient in
some respects. If you can post more details about it, I'd be
interested.
%
%- how much software works, how much breaks?  I have seen that the
%  vt52 screen used by .tos programs fails to scroll properly unless
%  you patch TOS or have a blitter.  Perhaps TurboST or QuickST could
%  fix this problem.
Ah, that's what I thought. Yeah, this scrolling problem is quite a
hassle. You can also see it in TOS 1.2 ROMs (like I had when I bought
my Mega. I think it's just the blitter code that's at fault. Also
had this problem with older versions of TurboST.)

I've found, much to my dismay, that the GEM VDI function vro_copyform
(and the corresponding Line-A function) clips at 640x400. This has
been kind of a pain; I suspect that there are more functions with this
limitation. Perhaps a newer version of the overscan software has been
written with the appropriate patches, I don't know.
%
%- How well does it work with colour in North America (I had heard of
%  problems).
It only works if the display is set to 50 Hz. I originally wrote a
two line program to set this and stuck it into my AUTO folder. This
was somewhat unsatisfactory, so I disassembled the overscan program
and made the changes in there.
%
%- can it be done to the STe?
Wish I could get my hands on an STe. Oh well...
%
%- is the screen readable?  I have a hard enough time reading "hi50"
%  text on my screen, even with the monitor tweaked to shrink the
%  boarders.  "hi60" must be worse.
I guess this is pretty subjective. I occasionally have a problem such
that the scan rate is off. The symptom is that the screen is shifted
left or right by about 6 pixels. Toggling the overscan switch back and
forth clears the problem. I like the "hi50/hi60" mode, I don't find it
particularly hard to read, and it makes editing source code that much
easier (more context onscreen).
%
%- does Spectre support this mode?
I don't have Spectre either. Not being much of a Mac afficionado these
days, I doubt I ever will...
%
%I think that your experiences with overscan are worth describing in
%the st newsgroup.  This note is to encourage you to keep it up.  If
%you can answer my questions, I recommend posting the reply to the net.
%
%Hugh Redelmeier
%?utcsri, yunexus, uunet!attcan, utzoo, hcr?!redvax!hugh
%When all else fails: [e-mail]
%[phone]

Well. There 'tis.

I've got a question I hope someone can answer... As I mentioned above,
the raster operations don't seem to work on rasters larger than the
standard 640x400 or 640x200. I had to write my own code to replace the
VDI calls in Uniterm to get some of the screen manipulation working.
Just now I encountered something that's got me really perplexed. I
copy the entire screen from the current logbase to an alternate buffer,
redraw stuff on the screen, then sometime later copy the entire buffer
back to the current logbase. In the meantime, to hide the fact that
this copy is occurring, I setscreen so the physical & logical screens
are pointed at the alternate buffer. This is just fine, the picture
looks perfect. But, when the original buffer is restored, the top row
of pixels is either scrambled or slightly offset (I haven't figured
out exactly what just yet...). The same routine
is used to do both copies, only the source and destination addresses
are swapped. I can't understand why the exact same routine copying
the exact same data winds up with not-the-exact-same result... ?
--
  -- Howard Chu @ University of Michigan

------------------------------

Date: 22 Jan 90 20:25:20 GMT
From:
 cs.utexas.edu!jarvis.csri.toronto.edu!utgpu!watserv1!watdragon!tiger!swklassen@
 tut.cis.ohio-state.edu  (Steven W. Klassen)
Subject: ST Format
Message-ID: <[e-mail]>

In article <[e-mail]> [e-mail] (M Davidson) writes:
>The UK magazine ST Format hasn't been doing Atari any favours recently.
>Just before Christmas it and its sister mag Amiga Format printed the
>story about how the Amiga developers turned down Atari and went to
>Commodore and how the ST was 'put together in a hurry'. This was rather
>damaging to the ST's sales, I know many people went for an Amiga because
>of this story - especially since the Amiga now sells for the same price
>as the 520ST.

I wouldn't worry too much about it.  It's too bad that the review
will probably hurt Atari sales (also hurting ST Format indirectly)
but I have read a few (3) issues of ST Format and my impression was
that it had no value other than the cover disk!

Of course this is just my opinion.



Steven W. Klassen                       +-----------------------------+
Computer Science Major                  | Support the poor...buy fur! |
University of Waterloo                  +-----------------------------+

------------------------------

Date: 22 Jan 90 20:15:14 GMT
From: brunix![e-mail]  (Rob Demillo)
Subject: ST S/ware Rental Places
Message-ID: <[e-mail]>

In article <[e-mail]>
 [e-mail] (Greg Lindahl) writes:
>This shouldn't be here, and it's my fault, but hopefully this,
>er, discussion will end here.
>
>In article <[e-mail]> [e-mail] (Rob Demillo) writes:
>[ quoting me ]
>>>Needless to say, it's extremely rude to call some people pirates
>>>because they rent software. Libraries rent books, video stores rent
>>>movies. Video stores rent Nintendo carts, which contain software.
>>>
>>
>>Sorry, Greg...I stand by my claim. And the Federal Trade Commission
>>stands with me, I'm afraid. (As does STart, BYTE, PC Week, etc. They no longer
>>accept advertising from software "rental" places.)
>
>Not all software rental places are pirates. Libraries let you check
>out software, are they pirates? Yes, *some* users rent software from
>rental places to pirate it. Others don't. If I did rent from such places
>(for example, I want to give Maple (costs $400) a test drive for a week
>to see if I want to spend that much on it), I'd be extremely offended
>if you called me a pirate. And you'd be wrong.
>

OK, Greg...you're a great guy. You'll *never* "borrow" software,
then copy it for yourself to keep. I'll accept that.

My accepting that fact from you is a *far* cry from condoning a
place taht "rents" software. For every "great guy" like you, I
would bet there is (at a bare minimum) one other person who wouldn't
think twice about stealing software. Those aren't terribly
good odds for a software rental place, are they?

You know, in almost every environment I've been in, I've
heard excuses for why people steal software: "It's easy,"
"It's too expensive," "I just wanted to test it out."

Now you want to give these people a legit license to walk out of
a place with software that they have no intention of ever buying?

>>Your analogies do not hold. If books were as easy to copy as software,
>>you can bet there would be similar complaints.
>
>Some books are easy to copy. One of my math textbooks cost $50, and
>I could have photocopied it for $10.

Cheap != Easy. How long would it take you to photocopy
the book? The same length of time it takes to copy a disk? I doubt it.

> I guess you'd want the library to not let me check out such books.

Oh, please....

>
>>Computer software is (currently) the *easiest* media to copy - and your
>>copy is an *exact* duplicate, not some scratchy re-recording of a record.
>
>Yes. That's why user education is so important. But the US was allegedly
>a free country last time I checked, and there is no excuse to prohibit
>legit activities.

Again: oh, please. Don't give me that crap - that's right out of
a bad movie. The US is a free country, huh? Try walking down the
street naked. Want to test your right of free speech? Try yelling
"Fire!" in a crowded movie theater. There are limits to your freedom.
Software rental places should be among those limits.

>I never said piracy hasn't hurt the software industry. I think it has.
>But education of users is the key, not being rude to random people.

You sound like Nancy Reagan. "Just say no." It has nothing to do
about educating people. Some people are just *criminals.* They don't
bother to think about software piracy, because its so "easy," and
why not?

I do, can, will not, understand this tendency by the public and the
media to group software piracy into its own, special little category.
It's theft. Period. Just like stealing a car - 'cept easier. Why make
it easier?

You want to test out the product? Do it in the store. If you want to
"test it out" for several days, that's several days worth of use you
have placed on the product. If you are going to do that, why not
send away for a products'  demo copy? If its a large package, they
are sure to have something, if its a small package - you're just
out of luck, aren't you?

>
>Don't forget the old saw about "Innocent until proven guilty." If
>renting software was only used for piracy, I'd think it was a bad
>thing. But renting software is useful for legitimate purposes. And I
>don't want to get called a pirate because I say renting can be ok.

I think it *has* been proven guilty. No one is calling *you* specifically
a pirate...but, as I said earlier, because you're a great guy, doesn't
me you can claim that software rental places haven't hurt the software
market...

 - Rob DeMillo                  | Internet: [e-mail]
   Brown University             | BITnet: [e-mail]
   Planetary Science Group      | Reality: 401-273-0804 (home)
"I say you *are* the Messiah, Lord! And I ought to know, I've followed a few!"

------------------------------

Date: 22 Jan 90 20:06:28 GMT
From: ucsdhub!hp-sdd!ncr-sd!tw-rnd![e-mail]  (John Lindwall)
Subject: TURBO C/MAS problem
Message-ID: <[e-mail]>

>I'm having a problem with the MAS assembler that comes with Turbo C v1.1.  The
> [etc]

Please don't flame me.

I came across this posting in the atari.st newsgroup.  Is the compiler being
discussed here actually Borland's Turbo C?  Is is some other company using
the name "Turbo"?  I am an Amiga owner and I sure wish Borland would market
there compilers for the Amiga (In fact Borland advertised Turbo Pascal in the
first issue of AmigaWorld but never delivered!).  Anyway, if this IS the
Borland Turbo Products, please inform me:

Which Borland compilers are available For ST's?  C? Pascal? etc..

How much do they cost?

Are they considered good ST compilers?

Any comments on the product/support/marketing/etc?

Thank you.



--
John Lindwall                     |   "Not my employer opinions; mine"
[e-mail]     |   a man, a plan, a beer, reeban alpa nama
----------------------------------+--------------------------------------------

------------------------------

End of INFO-ATARI16 Digest V90 Issue #81
****************************************